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Abstract.  Service  Oriented  Architectures  (SOA)  offers  the  DoD  the 
promise  of  cost  savings,  data  sharing,  interoperability,  and  increasingly 
agile  operations.  As  with  all  things  that  progress  in  society,  there  are 
obstacles.  One  of  the  challenges  faced  by  the  DoD  involves  molding 
current  acquisition  processes  and  cultures  to  be  SOA  friendly.  This 
paper  discusses  these  challenges  and  presents  some  thoughts  on 
how  they  might  be  addressed. 

Introduction 

Metcalf’s  Law  tells  us  that  the  value  of  a  telecom m unications 
network  is  proportional  to  the  square  of  the  number  of  users  of 
the  system  [1].  Service  Oriented  Architectures  (SOAs)  capital¬ 
ize  on  this  phenomenon.  Through  a  set  of  standard  interfaces, 
services  (i.e.,  software-based  capabilities)  are  made  available 
to  any  consumer  willing  to  follow  the  structural  and  behavioral 
rules  for  consumption.  The  loose  coupling  provided  by  standard 
interfaces  enables  this  plug-and-play  capability.  Taking  advan¬ 
tage  of  such  a  notion  promises  great  gains  in  efficiency  for 
anyone  looking  to  create  interoperable,  scalable  applications 
that  share  information  across  boundaries. 

According  to  Gartner,  SOA  will  be  used  in  more  than  80% 
of  mission-critical  operational  applications  and  business 
processes  by  the  year  2010  [2].  Analysis  of  the  literature 
indicates  that  the  SOA  vision  leads  to  a  belief  of  implementa¬ 
tion  efficiencies  and  cost  savings  of  epic  proportions.  As  the 
U.S.  DoD  moves  forward  with  its  vision  of  highly  distributed 
net-centric  capabilities  in  current  and  future  DoD  programs, 
it  will  be  difficult  to  deploy,  maintain,  and  evolve  capabilities 
without  the  benefit  that  SOA  brings  to  the  table. 


SOA  offers  the  DoD  the  promise  of  cost  savings,  data 
sharing,  interoperability  and  increasingly  agile  operations.  But, 
as  with  all  things  that  progress  in  society,  there  are  obstacles. 
The  DoD  depends  on  outside  contractors  to  develop  much  of 
its  needed  capabilities.  These  contracts  may  involve  delivering 
a  specific  platform,  such  as  a  quantity  of  F-22s  or  F-35s,  or 
they  may  require  the  delivery  of  a  set  of  capabilities  to  satisfy 
one  or  many  missions  such  as  Future  Combat  Systems  or 
Distributed  Common  Ground  Systems.  The  contractors  who 
deliver  these  capabilities  are,  not  surprisingly,  doing  so  for  a 
profit.  With  this  profit  as  a  motivator,  contractors  will  be  un¬ 
likely  to  choose  reusing  a  network-available  capability  when 
they  can  be  paid  to  develop  the  solution  themselves.  Incen¬ 
tives  are  needed  to  make  the  existing  capability  a  desirable 
option  for  the  contractor. 

In  addition  to  technical  challenges  associated  with  deploy¬ 
ing  solutions  that  take  advantage  of  service-oriented  technol¬ 
ogy,  there  are  cultural  and  organizational  challenges  that  the 
DoD  is  likely  to  encounter.  Contractors,  who  are  being  paid 
to  deliver  a  solution  or  a  capability  to  a  specific  customer,  are 
unlikely  to  think  beyond  their  contractual  obligations.  When 
developing  a  service,  a  contractor  will  be  uninspired  to  think 
about  the  bigger  picture,  especially  in  situations  where  there 
is  schedule  pressure  or  cost  containment  issues  (a  frequent 
occurrence  with  many  DoD  software  projects). 

This  paper  describes  Service  Oriented  Architecture  and  the 
potential  value  this  technology  could  bring  to  the  DoD.  It  then 
addresses  the  cultural  and  organizational  aspects  associated 
with  getting  quality  SOA  solutions  within  a  contract  develop¬ 
ment  scenario.  Finally,  some  suggestions  are  presented  for 
establishing  incentives  to  encourage  SOA-friendly  behavior 
within  such  a  scenario. 

What  is  a  Service  Oriented  Architecture? 

Service  orientation  is  not  a  new  concept.  We  are  all  provid¬ 
ers  and  consumers  of  services.  If  I  want  power  for  my  toaster, 

I  put  the  plug  into  the  wall  socket  and  power  flows.  I  require 
no  knowledge  of  how  the  power  gets  from  the  wall  socket 
into  the  toaster  or  what  substation  generates  the  power.  As  a 
service  consumer,  all  I  need  is  the  correct  interface  (my  plug) 
to  get  access  to  the  electricity,  and  a  Service  Level  Agree¬ 
ment  with  the  service  provider,  in  this  case  the  electric  com¬ 
pany,  which  indicates  my  willingness  to  pay  for  the  service. 
And  throughout  the  U.S.,  anyone  with  that  same  interface 
and  an  agreement  with  their  local  electric  company  can  get 
access  to  power  in  the  same  way. 

In  the  context  of  software,  a  Service  Oriented  Architec¬ 
ture  is  a  paradigm  that  offers  software  service  providers  the 
potential  to  share  their  software  solutions  with  consumers 
using  the  same  basic  business  model  that  utilities  have  used 
successfully  for  years.  Service  consumers  are  then  able  to 
reuse  capabilities  developed  by  others  rather  than  having  to 
develop  that  capability  themselves.  An  SOA  is  an  architectural 
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style  that  allows  for  distribution  of  capabilities  that  need  not 
all  be  supplied  or  owned  by  the  same  organization  or  entity, 
with  the  same  notion  of  transparency  that  utilities  offer  elec¬ 
tric  consumers.  From  the  DoD’s  perspective,  SOA  offers  the 
opportunity  to  create  solutions  that  get  the  right  information 
to  the  right  places  at  the  right  time. 

The  Value  of  SOA 

SOA  results  in  two  distinct  categories  of  software:  services 
(for  example  web  services  published  in  a  global  directory)  that 
are  published  and  made  available  by  service  providers,  and 
software  that  consumes  these  services  to  create  capabili¬ 
ties.  These  software  services  can  be  further  characterized  as 
either  infrastructure  services  required  by  many  software  ap¬ 
plications  (such  as  security,  messaging,  and  routing),  or  busi¬ 
ness  services  that  are  specific  to  business  requirements  or 
specific  missions.  Compare  this  to  more  traditional  software 
paradigms  where  the  business  or  mission-specific  capabilities 
are  closely  meshed  with  software  that  supports  the  infrastruc¬ 
ture  of  the  application.  Separating  the  infrastructure  from  the 
business  rules  makes  it  possible  to  respond  quickly  as  busi¬ 
ness  rules  or  mission  requirements  change.  SOA  creates  an 
environment  where  the  business  drives  IT  requirements  rather 
than  being  constrained  by  them.. 

By  definition,  SOA  services  are  to  be  reusable.  In  an  organi¬ 
zation  as  large  as  the  DoD,  the  existence  of  reusable  services 
creates  many  opportunities  to  reduce  redundancy  and  increase 
efficiency.  From  a  mission  effectiveness  perspective,  there  are 
many  areas  where  SOA  could  add  value.  SOA  promises  to 
increase  interoperability  within  and  among  the  services  through 
discoverable  standardized  service  contracts.  Through  reusable 
data  services,  information  can  be  shared  across  the  enterprise 
increasing  dissemination  and  knowledge  transfer.  Readiness 
can  be  improved  through  efficiencies  gained  in  information 
access.  Additionally,  widespread  SOA  throughout  the  DoD  will 
increase  organizational  ability  to  deal  with  rapid  change. 

The  SOA  Acquisition  Challenge 

It’s  not  too  hard  to  see  that  SOA  may  add  value  to  the  DoD 
but  there  are  certainly  some  technological  challenges  that 
must  be  overcome.  Challenges  aren’t  going  to  stop  smart 
software  professionals  from  developing  and  delivering  quality 
software  to  the  DoD.  There  are,  however,  some  cultural  and 
organizational  challenges  that  may  stand  in  the  way  of  suc¬ 
cessful  transition  to  SOA. 

Imagine  a  contractor  who  has  been  awarded  the  contract 
(hypothetical)  to  develop  a  capability  to  store  food  allergy 
data  for  all  of  the  Army’s  soldiers  and  disseminate  this  infor¬ 
mation  to  all  locations  where  the  soldiers  are  fed— including 
military  bases,  theaters  of  operation,  military  hospitals,  etc. 
While  developing  the  data  services  to  process  this  informa¬ 
tion,  the  contractor’s  software  engineering  team  realizes 
that  developing  a  more  generic  service  to  handle  all  types 


of  allergies— including  food,  drug,  bee  stings,  etc.— would  be 
a  more  valuable  service  to  the  DoD  as  a  whole.  At  the  same 
time,  the  customer  program  team  realizes  that  this  more 
useful  service  will  take  more  time  and  resources  to  develop; 
time  and  resources  not  currently  in  the  budget.  The  contrac¬ 
tor’s  customer  program  team  abandons  good  SOA  practices 
(facilitating  a  more  widely  useable  service)  to  create  a  point 
solution  to  the  problem  because  there  is  no  organizational 
means  to  quickly  adjust  the  schedule  and  budget. 

This  is,  of  course,  a  very  simplified  example— many  opportu¬ 
nities  will  arise  that  could  provide  useful  solutions  throughout 
the  DoD  that  may  be  overlooked  because  funding  is  targeted 
at  specific  capabilities.  A  project  is  not  service-oriented  just 
because  capabilities  are  delivered  using  sharable  services.  A 
project  is  not  truly  service-oriented  unless  it  takes  advantage 
of  existing  services  where  available  and  develops  needed 
services  taking  into  account  the  bigger  picture  of  uses  be¬ 
yond  the  current  need.  DoD  contracts  focus  on  the  particular 
capability  being  contracted  for  and  make  no  provisions  for 
delivering  beyond  that.  Contractors  are  paid  for  the  capability 
they  deliver,  making  it  desirable  to  maximize  capability  devel¬ 
oped  for  a  specific  contract.  This  is  not  to  suggest  that  the 
contractors  for  particular  projects  should  be  responsible  for 
the  creation  and  maintenance  of  an  SOA  framework  suitable 
to  meet  DoD  requirements.  Contractors  working  on  specific 
projects  should  intend  to  take  advantage  of  existing  DoD 
SOA  frameworks.  Contractors  however,  should  be  encour¬ 
aged  to  embrace  SOA  for  their  projects  by  leveraging  the  use 
of  services  existing  within  that  framework  and  considering  the 
greater  good  when  developing  new  services  to  be  made  avail¬ 
able  through  that  framework. 

In  this  way,  SOA  creates  a  paradox  for  the  DoD  and  its 
contractors.  The  DoD  has  specific  capabilities  that  it  knows 
it  needs  and  it  has  a  time  frame  and  budget  within  which  it 
expects  to  meet  those  needs.  Within  the  DoD,  the  “sponsor” 
of  a  specific  capability  will  outsource  the  fulfillment  of  this 
capability  to  a  community  of  engineers,  designers  and  other 
software  development  personnel.  Neither  the  sponsor  nor  the 
contractor  is  rewarded  or  incentivized  to  provide  a  service- 
based  solution,  which  meets  a  greater  good  and  provides 
additional  enterprise  benefit  for  the  whole  of  the  DoD.  There 
are  limited  explicit  incentives  to  take  advantage  of  existing 
services  when  possible  that  meet  program  needs.  The  DoD 
has  unwittingly  tied  the  hands  of  these  very  talented  profes¬ 
sionals  by  not  providing  a  mechanism  to  encourage  a  specific 
focus  on  enterprise  benefit. 

Cultural  and  organizational  changes  are  necessary  if  the 
DoD  is  going  to  be  successful  with  full-scale  SOA  solutions. 
Contractors  and  project  sponsors  should  be  encouraged 
through  policy  changes  and  funding  incentives  to  think  be¬ 
yond  the  current  problem.  Both  the  contractor  and  customer 
sponsor  need  to  be  incentivized  to  develop  services  that  will 
solve  problems  the  DoD  might  not  yet  realize  that  they  have— 
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1  —  Contractor  present  idea  with  cost  savings  as  part  of  assessment 
1  —  Functional  Capabilities  Board  (FCB)  responsible  for  assessing 

capabilities,  priorities,  and  tradeoffs  across  the  range  of  functional  areas 


or  issues  that  might  not  be  relevant  to  the  contracting  agency 
but  that  could  have  significant  impact  on  another  agency. 
Suppose  there  was  a  process  through  which  contractors 
can  come  back  to  the  table  during  the  planning  and  require¬ 
ments  phases  of  a  project  with  suggestions  for  a  better,  more 
far-reaching  SOA  solution  than  that  which  was  originally 
contracted.  Figure  1  depicts  a  notional  process. 

Contractors  should  be  given  opportunities  to  identify  en¬ 
hanced  SOA  solutions  to  the  contracting  agency.  This  oppor¬ 
tunity  could  be  presented  to  the  DoD  sponsors,  outlining  addi¬ 
tional  costs  as  well  as  added  value  of  the  enhanced  solution. 
Additionally  the  contractor  should  present  the  cost  savings 
anticipated  if  the  enhanced  service  is  provided  in  the  context 
of  the  current  program  versus  having  to  do  it  separately  as 
a  new  program  or  upgrade.  Once  the  DoD  sponsor  validates 
the  new  solution,  the  improvements  would  be  passed  on  to 


the  Functional  Capabilities  Board  for  approval.  Ideally,  the 
contractor  and  the  DoD  sponsor  would  be  given  the  opportu¬ 
nity  through  this  mechanism  to  present  suggestions  not  only 
to  the  contracting  agency,  but  to  other  branches  of  the  DoD 
that  might  benefit  from  such  a  service.  Upon  validation  of  the 
value  added  by  the  new  service,  a  portion  of  the  cost  savings 
incurred  could  then  be  provided  as  both  an  award  fee  incen¬ 
tive  to  the  contractor  and  a  budget  increase  to  the  sponsor. 

There  should  also  be  incentives  for  contractors  to  include 
reuse  of  existing  services  as  part  of  their  bid  for  the  contract. 
Contractors  should  be  encouraged  to  work  with  the  contract¬ 
ing  agencies  and  a  Functional  Capabilities  Board  to  identify 
services  existing  in  either  the  DoD  or  the  public  domain 
that  would  be  suitable  in  the  context  of  the  current  contract. 
Contract  awards  should  include  provisions  for  a  “finder’s  fee” 
based  on  the  anticipated  savings  to  the  contracting  agency, 
taking  into  consideration  not  only  reduced  costs  for  the  cur¬ 
rent  program  but  also  recognizing  the  value  in  non-duplication 
of  services. 

Conclusion 

SOA  is  likely  here  to  stay.  It  offers  great  opportunities  for 
the  Services  and  the  entire  DoD  to  develop  forward-thinking 
synergistic  solutions  that  transcend  current  operational 
requirements.  In  order  for  this  to  happen,  the  DoD  needs  to 
find  ways  to  encourage  contractors  and  DoD  sponsors  to 
embrace  SOA  beyond  just  the  “letter  of  the  law”  to  the  point 
where  they  are  architecting  solutions  designed  to  take  ad¬ 
vantage  of  the  benefits  and  cost  savings  possible  with  SOA. 

On  the  other  hand,  contractors  need  to  be  proactive  in  their 
approach  to  providing  quality  SOA  solutions  to  the  DoD  that 
consider  requirements  beyond  a  current  contract  and  look  to 
how  contract  solutions  can  add  value  beyond  that  contract  to 
other  applications  across  the  DoD  enterprise. 

As  SOA  evolves  within  the  DoD,  acquisition  culture  needs 
to  shift  to  enable  collaborative  behavior  that  will  provide 
solution  synergy.  The  DoD  will  benefit  by  getting  the  most 
value  out  of  services  contracted  for  particular  programs.  The 
contractors  benefit  as  their  proactive  behavior  in  defining 
opportunities  makes  them  a  vital  part  of  the  DoD’s  SOA  plan¬ 
ning  process,  bringing  them  to  the  table  as  the  DoD  works  to 
create  SOA  Advisory  Boards  and  SOA  Centers  of  Excellence.^ 
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